IRIX Base Documentation 2001 May

home *** CD-ROM | disk | FTP | other *** search

/ IRIX Base Documentation 2001 May / SGI IRIX Base Documentation 2001 May.iso / usr / share / catman / p_man / cat5 / dso.z / dso

Wrap

Text File | 2001-04-17 | 74.1 KB | 1,281 lines

DSO(5) Last changed: 1-29-99 NNAAMMEE DDSSOO - Dynamic Shared Object (DSO) IIMMPPLLEEMMEENNTTAATTIIOONN IRIX systems DDEESSCCRRIIPPTTIIOONN This man page describes Dynamic Shared Objects (DSOs). It is divided into the following 4 sections: * Overview * Linking and building DSOs * Performance considerations * Frequently asked questions OOVVEERRVVIIEEWW A DSO is an ELF format object file. It is very similar in structure to an executable program, but it has no main program. It has the following components: * A shared component, which consists of shared text and read-only data. * A private component, which consists of data and the Global Offset Table (GOT). * Several sections that hold information needed to load and link the object. * A lliibblliisstt, which is the list of other DSOs referenced by this object. Most libraries supported on IRIX platforms are available as DSOs. PPoossiittiioonn IInnddeeppeennddeenntt CCooddee ((PPIICC)) A DSO is relocatable at runtime; it can be loaded at any virtual address. A consequence of this is that all references to external symbols must be resolved at runtime. References from a private region (that is, from private data) are resolved at load time. References from a shared region (that is, from shared text) go through the indirection table, which is also called the Global Offset Table (GOT), and incur a small performance penalty. The GOT helps facilitate Position Independent Code (PIC). PIC is code that satisfies references indirectly by using the GOT, which allows code to be relocated simply by updating the GOT. Each executable and each DSO has its own GOT. The GOT is a data table with the actual addresses of global data with appropriate code generation and linking support. The linker, lldd(1), constructs the GOT. PIC satisfies references indirectly by using the GOT, which allows code to be relocated simply by updating the GOT. PIC can be shared by multiple users. Each program must have its own data space. Code sharing and independent data is arranged automatically by the compilation and run-time systems. Code compiled for use in a DSO is PIC. Non-PIC code is usually referred to as non-shared. Non-shared code and PIC cannot be mixed in the same object. WWhhaatt HHaappppeennss aatt RRuunnttiimmee?? The runtime events are as follows: 1. eexxeecc(2) loads the main program and then loads one of the following interpreters as specified in the main program: * //uussrr//lliibb//lliibbcc..ssoo..11 is loaded for programs compiled with the --3322 compiler option. * //uussrr//lliibb3322//lliibbcc..ssoo..11 is loaded for programs compiled with the --nn3322 compiler option. * //uussrr//lliibb6644//lliibbcc..ssoo..11 is loaded for programs compiled with the --6644 compiler option. 2. The interpreter loads rrlldd(5), the runtime linking loader, which finishes the eexxeecc(2) operation. Starting with the main program's lliibblliisstt, rrlldd(5) loads each DSO on the list that is not marked to be delay-loaded. rrlldd(5) reads that object's lliibblliisstt and repeats the operation until all DSOs have been loaded, in a breadth-first manner. The breadth first loading process, which ignores objects marked to be delay-loaded, results in defining a sequence of objects. 3. rrlldd(5) allocates storage for COMMON block symbols and fixes up symbolic references in each loaded object. This is necessary because the location at which the object will be loaded is not known until runtime. To look up a given symbol in the process of fixing up symbolic references, rrlldd(5) examines each object's dynamic symbol table. If rrlldd(5) finds a strong symbol that satisfies the reference (that is, it has the name of the given symbol and is an external definition) it stops with that symbol. If it does not find a strong definition with that name, then the first weak symbol found is accepted as the definition. 4. Each object's --iinniitt code is executed. This is code specified as an argument to the --iinniitt option on the lldd(1) command. For information on --iinniitt code, see lldd(1). 5. Control transfers to ____ssttaarrtt in the main program. The sequence at which the --iinniitt code is run is important to applications and DSOs that have --iinniitt code. By default, objects are taken in reverse order of the sequence defined in loading. If --iinniitt code in one DSO calls a DSO with --iinniitt code that has not yet run, then the --iinniitt code in the called DSO is run before the called DSO routine is actually called. Thus, the default order is not followed. It is not an error for DSOs to mutually call one another, even indirectly, from within --iinniitt sections, but the resulting DSO ordering can be confusing and can vary depending on actions in the application --iinniitt code. The --iinniitt code in delay-loaded DSOs is not run until the DSO is actually loaded, and the delay-loaded DSO is loaded when some routine in the delay-loaded DSO is called. Do not include calls to sspprroocc(2), nnsspprroocc(2), sspprrooccsspp(2), or any POSIX threads (pthreads) routines from within --iinniitt or --ffiinnii code. The following table describes the problem with --iinniitt and --ffiinnii code in pthreads and sspprroocc(2) applications: -------------------------------------------------------------------- ssiiggpprrooccmmaasskk((22)) GGeettttiinngg ssiiggpprrooccmmaasskk((22)) SSeettttiinngg TThhrreeaaddss?? MMaasskk BBiittss MMaasskk BBiittss -------------------------------------------------------------------- sspprroocc(2) threads Sees more masked than Settings lost on exit non-init. of --iinniitt and --ffiinnii. pthreads Sees more masked than Application settings non-init. preserved. No threads Sees true setting. Application settings preserved. -------------------------------------------------------------------- The preceding table entries can be explained as follows: * In the TThhrreeaaddss?? column, An sspprroocc(_2) _t_h_r_e_a_d_s application is one that is using sspprroocc(2), nnsspprroocc(2), or sspprrooccsspp(2). A _p_t_h_r_e_a_d_s application is one that has lliibbpptthhrreeaadd..ssoo linked in. A _N_o _t_h_r_e_a_d_s application is any other application. * _S_e_e_s _m_o_r_e _m_a_s_k_e_d _t_h_a_n _n_o_n-_i_n_i_t means that --iinniitt and --ffiinnii code do not get the true mask bits. Instead, nearly all signals are marked as masked. * _S_e_t_t_i_n_g_s _l_o_s_t _o_n _e_x_i_t _o_f --iinniitt _a_n_d --ffiinnii means that on exit of the nested set of --iinniitt or --ffiinnii functions, the set of mask bits set on entry to the functions is restored. Any setting done by the --iinniitt or --ffiinnii code is lost. * _A_p_p_l_i_c_a_t_i_o_n _s_e_t_t_i_n_g_s _p_r_e_s_e_r_v_e_d means that the ssiiggpprrooccmmaasskk(2) bit settings that are made by the --iinniitt or --ffiinnii code are preserved on exit of the --iinniitt or --ffiinnii function set. * _S_e_e_s _t_r_u_e _s_e_t_t_i_n_g means that the mask bits that ssiiggpprrooccmmaasskk(2) returns to --iinniitt and --ffiinnii code are the true application mask bits. As the preceding table shows, the complexities with signal masks inhibit successful ssiiggpprrooccmmaasskk(2) operation in --iinniitt or --ffiinnii code. Generally, the results are not going to be what is desired. Also ignored, in theory, are symbols in any DSO that is loaded at runtime because it is on the lliibblliisstt of a DSO opened by ddllooppeenn(3C) or ssggiiddllooppeenn__vveerrssiioonn(3C). rrlldd(5) makes the lliibblliisstt DSO symbols visible, but no application should count on this visibility. However, if a DSO's symbols are visible for any reason (for example, because it was in the main program's lliibblliisstt), that DSO is not hidden just because it is also on the library list of a DSO opened with ddllooppeenn(3C) or ssggiiddllooppeenn__vveerrssiioonn(3C). When execution terminates, the --ffiinnii code of each DSO and the base aa..oouutt file is run in the opposite order the actual --iinniitt code was run (or would have been run, in the case of DSOs with --ffiinnii code but no --iinniitt code). --ffiinnii code and --iinniitt code consist of code specified as an argument to the lldd(1) For more information on --ffiinnii code and --iinniitt code, see the rest of this man page and see lldd(1). Other factors can affect the general load process, too. For more information, see the information on Quickstart and delayed loads on this man page and see the ssggiiddllaadddd(3C), ssggiiddllooppeenn__vveerrssiioonn(3C), and ddllooppeenn(3C) man pages. --iinniitt CCooddee RRuunnttiimmee OOrrddeerriinngg The general order in which the base executable DSO's --iinniitt code is run is specified by the MIPS Application Binary Interface (API). For more information on this ABI, see the URLs mentioned in the SEE ALSO section. Before an --iinniitt in object AA is run, you can assume that all --iinniitt sections in DSOs that AA depends on have been run. However, if --iinniitt code calls a DSO with --iinniitt code that has not yet run, the --iinniitt code of the called DSO is run first. The physical ordering starts with the last DSO in rrlldd(5)'s list and works toward the executable file. This is a depth-first postorder call of --iinniitt code. This is a particular choice of ordering within the conceptual framework. The physical ordering is not specified by the MIPS ABI. The run order of delay-loaded DSOs and DSOs that have been opened by ddllooppeenn(3C) is recorded so that --ffiinnii operations occur in reverse order. Any DSO that is delay-loaded during the execution of --iinniitt code changes the order in which --iinniitt sections are run. The actual manner of the changes is difficult to predict. At the time of the delay-load, the --iinniitt code scan is restarted anew (new due to the new DSO) at the end of rrlldd(5)'s list. --ffiinnii CCooddee RRuunnttiimmee OOrrddeerriinngg The --ffiinnii code of the DSOs in the base executable is run choosing DSOs in the opposite order the actual --iinniitt code was run (or would have been run, in the case of DSOs with --ffiinnii code but no --iinniitt code). LLiimmiittaattiioonnss oonn --iinniitt aanndd --ffiinnii CCooddee In most versions of rrlldd(5), --iinniitt and --ffiinnii code could not successfully perform delay-load operations, such as ddllooppeenn(3C), ssggiiddllaadddd(3C), ddllssyymm(3C), ddllcclloossee(3C), or implicit delay-load operations, if the application used sspprroocc(2), sspprrooccsspp(2), nnsspprroocc(2), or pthreads. Threaded applications hung if such operations were included in --iinniitt or --ffiinnii code or were nested codes outside of --iinniitt or --ffiinnii code. The current release of rrlldd(5), however, supports nested delay-load operations, but it is unwise to depend too much on this support. For example, it is unwise to use delay-loading with C++ global initialization code because much about the interaction of name resolution (name binding and symbol binding) with nested delay-load operations is unspecified. For example, calling a delay-load routine or calling delay-loaded functions in different orders depending on startup conditions means that the ordering of DSOs on rrlldd(5)'s list of DSOs may vary. If the order varies and there are multiple definitions of an external (different functions with the same name), exactly what is executed from run to run may differ. Considering that is it difficult, in C++, to control the sequence in which different compilation units --iinniitt code is executed, and potentially, you have serious application problems. It is also difficult to debug such code as debuggers often have difficulting intercepting calls in --iinniitt sections. In multithreaded programs, --iinniitt and --ffiinnii code should avoid attempts to acquire (by using pptthhrreeaadd__mmuutteexx__lloocckk(3P), for example) resources owned by other threads, unless it can be guaranteed that the other thread can release the resource without performing a delay-load operation or lazy text resolution. Should the thread owning the resource make a call into rrlldd(5), the threads deadlock. It is difficult to predict whether execution of a given section of code requires lazy text resolution. A DSO's GOT can be reset to point at function stubs when it fails to Quickstart or after delay-load operations that might affect resolution of its symbols. See the section on Quickstart in the PERFORMANCE CONSIDERATIONS section of this man page for more information on function resolution. The C++ runtime system uses the --iinniitt and --ffiinnii mechanism to construct and destroy static objects. Therefore, constructors and destructors for such objects should avoid blocking calls if DSOs using them are to be manipulated by ddllooppeenn(3C) or ddllcclloossee(3C) or are to be delay-loaded within a multithreaded program. LLIINNKKIINNGG AANNDD BBUUIILLDDIINNGG DDSSOOss Assume that your library is in an archive lliibbffoooo..aa of object files, all of which have been compiled with the lldd(1) command's --sshhaarreedd option. The library references symbols found in lliibbcc..ssoo..11, lliibbggll..ssoo, lliibbXX1111..ssoo, and lliibbnneettllss..ssoo, but most programs never use the path that requires lliibbnneettllss..ssoo. It is recommended that you build your DSO, lliibbffoooo..ssoo, in the following way: ld -elf -shared -no_unresolved -rdata_shared -soname libfoo.so -o libfoo.so -all libfoo.a -lX11 -delay_load -lnetls -lc -lgl This builds a DSO called lliibbffoooo..ssoo that directs rrlldd(5) to load lliibbcc..ssoo..11, lliibbXX1111..ssoo, and lliibbggll..ssoo whenever lliibbffoooo..ssoo is loaded. This command line also loads lliibbnneettllss..ssoo if it is ever referenced. NNOOTTEE:: If you have any C++ object files among the objects making up your DSO, you must replace lldd in the previous example command with CCCC. That is, your command line should be as follows: CC -elf -shared ... -o libfoo.so -all libfoo.a ... However, you do not have to do anything special at all to use such C++ DSOs when linking other programs against these DSOs. You can link C++ DSOs into C, C++, or Fortran programs using your usual link commands or link other DSOs against these C++ DSOs without taking any special action. For example, the following command line links the preceding C++ DSO lliibbffoooo..ssoo properly: f77 fortran_prog.o -lfoo CCoonnttrroolllliinngg SSyymmbboollss EExxppoorrtteedd bbyy aa DDSSOO One benefit from using DSOs is the ability to release new versions of an object and be assured that objects linked against the old version will work with the new version. This is impossible to guarantee, however, if the set of symbols exported by an object cannot easily be understood by the object's creator. lldd(1) provides several options to help you control the symbols that are exported by a DSO. By default, lldd(1) does not export symbols that are supplied by a linked-in archive or DSO. The developer is probably only a consumer of the linked-in object, not an exporter. In a subsequent release, the developer may not require the linked-in object, and if the symbols provided by the linked-in object had been exported by the developer's object, the new object would no longer be upwardly compatible with the original version. This behavior can be overridden by using the --eexxppoorrttss option on the lldd(1) command. This default symbol hiding behavior, with respect to archives, is also overridden when building a DSO from an archive using the --aallll option. You can control the list of symbols that are exported by using the following lldd(1) options: --eexxppoorrtteedd__ssyymmbbooll, --eexxppoorrttss__ffiillee, --eexxppoorrttss, --hhiiddeess, --hhiiddddeenn__ssyymmbbooll, and --hhiiddeess__ffiillee. The first two options let you specifically list the symbols to be exported by the DSO. The eexxppoorrtteedd__ssyymmbbooll option is followed by a comma-sepatated list of names. The eexxppoorrttss__ffiillee option accepts a file name that contains a space-separated (including newlines) list of names. If any symbols are specifically exported, only those symbols are exported. All other symbols are automatically hidden. The last two options specify a list of symbols that are not to be exported by the DSO. For more information on the lldd(1) options, see the lldd(1) man page. There are two consequences of hiding symbols. First, those symbols do not provide resolution to any undefined symbols in an object that links in the DSO. Second, any references to those symbols within the DSO are resolved internally to the hidden symbol. RRuulleess ooff TThhuummbb The following list contains things to remember when using the lldd(1) command: * Use the --nnoo__uunnrreessoollvveedd option to find unresolved symbols. It is not always possible to supply all the DSOs that will be referenced by lliibbffoooo..ssoo on the link line, but in general, libraries should be self-contained. This is especially true for subsequent releases of a DSO. If a DSO has any unresolved references, they must be resolved by some other loaded object. Having unresolved symbols invites disaster because there is no guarantee that the symbols will be resolved. Thus, the application may not run. * Link against the minimum set of ..ssoo files needed. Loading a DSO carries a cost. Linking against unneeded DSOs causes them to be loaded even if they are never referenced. lldd(1) issues a message when you have linked against a DSO that resolves no symbols. * When building a C++ DSO, specify the --eexxppoorrttss option for any DSO that provides the definitions of classes from which classes in the object being created are derived. Specifying --eexxppoorrttss in this case ensures that consumers of the object being created can create subclasses of classes provided by that object without having to know the complete set of DSOs that need to be loaded. Using the --eexxppoorrttss option in this case may bring in unwanted symbols. Use the --eexxppoorrtteedd__ssyymmbbooll, --eexxppoorrttss__ffiillee, --hhiiddddeenn__ssyymmbbooll, or --hhiiddeess__ffiillee options where appropriate. * Use the --rrddaattaa__sshhaarreedd option to move all read-only data into the shared segment. Unfortunately, many programs write to supposedly read-only data. The --rrddaattaa__sshhaarreedd option is disabled by default for this reason. The --uussee__rreeaaddoonnllyy__ccoonnsstt compiler option is enabled by default. * If you reference one of the graphics libraries, either lliibbggll..ssoo or lliibbGGLL..ssoo, put the library last in the link line. Often lliibbggll..ssoo cannot be Quickstarted. Putting it last allows all prior objects to be Quickstarted. You can also choose to delay-load the graphics libraries. This allows your application to Quickstart. For information on Quickstart, see the PERFORMANCE CONSIDERATIONS section of this man page. * Anytime a referenced object changes, you should either relink, in order to Quickstart, or you should run the reQuickstart tool rrqqss(1) on the object. * Try to minimize inter-DSO data references. * Try to minimize the use of global data. In DSOs, it is generally more efficient to allocate space when needed, using mmaalllloocc(3C) or mmaalllloocc(3F), rather than to use a large static data structure. * Try to pack data together that is likely to be unmodified. This allows the kernel to make more of the data pages shared, copy-on-write. * Use the --ddeellaayy__llooaadd option on any DSO on the link line that is not often used. This incurs a small performance penalty for the references to it, but this can save time and memory for those programs that don't use it. In addition, using this option on programs that have --iinniitt or --ffiinnii code also incurs a performance penalty. * Do not call any of the following from code that may be executed during processing by the --iinniitt or --ffiinnii options: ddllcclloossee(3C), ddlleerrrroorr(3C), ddllooppeenn(3C), ddllssyymm(3C), nnsspprroocc(2), sspprroocc(2), sspprrooccsspp(2), ssggiiddllaadddd(3C), and ssggiiddllooppeenn__vveerrssiioonn(3C). * Avoid having weak and strong versions of a symbol that are loaded into memory at different times (by a --ddeellaayy--llooaadd option or by ssggiiddllaadddd(3C) or ddllooppeenn(3C) calls). * Avoid performing a ddllcclloossee(3C) on an object that has been opened by ssggiiddllaadddd(3C). * Try to avoid using --iinniitt code by not using the option and by avoiding definition of C++ global objects that require --iinniitt code for construction. PPEERRFFOORRMMAANNCCEE CCOONNSSIIDDEERRAATTIIOONNSS The following subsections describe verious performance considerations. QQuuiicckkssttaarrtt When building a DSO or an executable, lldd(1) assigns addresses to the object and attempts to resolve all references. At runtime, if rrlldd(5) verifies that the same set of objects are loaded at the original addresses, then rrlldd(5) can skip all the runtime relocation work and let the program run. This saves time because the relocations are not performed, and it saves memory because rrlldd(5) does not have to read in the sections that hold the relocation information. At static link time, lldd(1) resolves each unresolved function call. When an unresolved function is called at runtime, rrlldd(5) performs the relocation needed for all future calls to the original function. In this way, more programs can Quickstart even if some of the function references are not resolved at static link time. Quickstart fails if the DSOs on a system do not match the objects used when linking either the application or the DSOs upon which the application depends. This can occur if a new version of a DSO is released. You can use the rrqqss(1) command to recalculate the Quickstart information associated with an application or a DSO. rrqqss(1) must be called in proper order so that DSOs on an object's lliibblliisstt are reQuickstarted before the object is reQuickstarted. rrqqss(1) rewrites the object it is reQuickstarting back in place. You can use the lldd(1) command's --nnoo__rrqqss option to mark an object as non-reQuickstartable. AAvvooiiddiinngg GGrraattuuiittoouuss SShhaarreedd OObbjjeecctt LLooaaddss rrlldd(5) does a considerable amount of work and can use up large amounts of real memory, so it is better not to link against DSOs that are not needed. RReedduucciinngg tthhee NNuummbbeerr ooff CCoonnfflliiccttss A _c_o_n_f_l_i_c_t arises whenever more than one DSO (including the main program) needed by an executable defines and uses the same name for a symbol. The name for which multiple definitions exist is recorded in your program in the section named ..ccoonnfflliicctt. The names of all conflicting symbols pertaining to a program can be obtained by using --DDcc flag to eellffdduummpp(1). One example of a conflict is the mmaalllloocc routine, which is defined both in lliibbcc..ssoo..11 and in lliibbmmaalllloocc..ssoo. Conflicts represent extra work to be done at startup because the presence of a conflict means that the objects in the link may not have chosen a consistent instance of the symbol in question. This extra work is memory-intensive because even one conflict can mean that many pages of memory must be examined by rrlldd(5). This intensive examination would otherwise not be needed for a Quickstarting program. The lldd(1) command's --qquuiicckkssttaarrtt__iinnffoo option causes lldd(1) to issue a warning about every conflict it finds and to write the names of two of the objects in which it is defined. Of course, sometimes conflicts are a necessary design component of certain applications. DDeellaayyeedd LLooaaddss The overhead associated with objects that are referenced but seldom used can be mitigated by using ddllooppeenn(3C), ssggiiddllooppeenn__vveerrssiioonn(3C), ssggiiddllaadddd(3C), or delayed loads. Using any of these delays the loading of a DSO (and the objects on its lliibblliisstt) until it is actually referenced. The --ddeellaayy__llooaadd option on the lldd(1) command is the easiest and most convenient to use. All three require that there be no references from any other object's data section to the delay-loaded DSO. FFRREEQQUUEENNTTLLYY AASSKKEEDD QQUUEESSTTIIOONNSS This section contains answers to frequently asked questions. The questions and their answers are as follows: 11.. WWhhaatt iiss aa DDSSOO?? DSO stands for _D_y_n_a_m_i_c _S_h_a_r_e_d _O_b_j_e_c_t. DSOs give applications the ability to share the text of heavily used libraries, which need not be included in the executable file. 22.. HHooww ddoo II mmaaiinnttaaiinn bbiinnaarryy ccoommppaattiibbiilliittyy bbeettwweeeenn vveerrssiioonnss ooff DDSSOOss?? Binary compatibility is maintained as long as the DSOs maintain the same exported symbols, add new symbols without removing any or changing semantics, and don't change exported structures. The ordering of symbols, routines, and global data is irrelevant. 33.. WWhhaatt oobbjjeecctt ffiillee ffoorrmmaatt ddoo DDSSOOss uussee?? DSOs use the ELF object file format as defined in the SVR4 ABI. 44.. HHooww ddoo II iinnssttaallll tthhee ttoooollss ssoo II ccaann uussee DDSSOOss oonn mmyy ssyysstteemm?? To compile and build DSOs, you need to nstall the IRIX Development Foundation (IDF) and the IRIX Development Libraries (IDL); these were formerly known as the Developer's Option. In addition, you must have a compiler. 55.. HHooww ddoo II bbuuiilldd aann eexxeeccuuttaabbllee ffiillee tthhaatt uusseess aa DDSSOO?? A command line like the following links mmyyffiillee..cc with lliibbmmiinnee..ssoo and with lliibbcc..ssoo..11: cc myfile.c -lmine If lliibbmmiinnee..ssoo is not available, but lliibbmmiinnee..aa is available, lliibbmmiinnee..aa is used along with lliibbcc..ssoo..11, and you get dynamic linking. To explicitly state that you want the DSO to be used, add the --ccaallll__sshhaarreedd option to the cccc(1) line, as follows: cc -call_shared myfile.c -lmine 66.. HHooww ddoo II bbuuiilldd aann eexxeeccuuttaabbllee ffiillee tthhaatt ddooeess nnoott uussee sshhaarreedd lliinnkkiinngg?? Use the --nnoonn__sshhaarreedd option, as follows: cc -non_shared myfile.c -lmine Some libraries are not available as nonshared. The ones that are available are not installed by default, so you must request their installation. In general, the --nnoonn__sshhaarreedd option is outmoded. 77.. HHooww ddoo II tteellll iiff aann eexxeeccuuttaabbllee ffiillee wwiillll uussee ddyynnaammiicc lliinnkkiinngg?? Entering the following command generates the ELF program header: elfdump -o This header contains all the information necessary for eexxeecc(2) and rrlldd(5) to run the program or DSO. Only aa..oouutt files that use dynamic linking have a PPHHDDRR, IINNTTEERRPP, or DDYYNNAAMMIICC entry. An example and a more detailed description is as follows: % elfdump -o /bin/cat ***PROGRAM HEADER*** Type Offset Vaddr Paddr Filesz Memsz Align RWX PHDR 0x00000034 0x00400034 0x00400034 0x000000c0 0x00000000 0x00000004 r-- INTERP 0x00000100 0x00400100 0x00400100 0x00000009 0x00000009 0x00000004 r-- REGINFO 0x00000110 0x00400110 0x00400110 0x00000018 0x00000018 0x00000004 r-- DYNAMIC 0x00000150 0x00400150 0x00400150 0x00000a70 0x00000a70 0x00000010 r-- LOAD 0x00000000 0x00400000 0x00400000 0x00003000 0x00003000 0x00001000 r-x LOAD 0x00003000 0x10000000 0x10000000 0x00001000 0x00001290 0x00010000 rwx Each line is an entry in the program header and refers to a _s_e_g_m_e_n_t of the file, as follows: LLiinnee SSeeggmmeenntt PPHHDDRR Points to the program header itself within the file. Only executable files that use dynamic linking have this field. IINNTTEERRPP Points to the location of the name of the interpreter required for this program. For any old 32-bit ABI object, compiled with --3322, this is //uussrr//lliibb//lliibbcc..ssoo..11. For any new 32-bit ABI object, compiled with --nn3322, this is //uussrr//lliibb3322//lliibbcc..ssoo..11. For any 64-bit ABI object, compiled with --6644, this is //uussrr//lliibb6644//lliibbcc..ssoo..11. RREEGGIINNFFOO Points to the location of the register setup information. This information can be seen by entering the eellffdduummpp --rreegg command. For the old 32-bit ABI, obtained when compiling with --3322, this consists of the correct global pointer (gp) value for this object. For the new 32-bit or 64-bit ABIs, obtained when compiling with --nn3322 or --6644, this entry does not appear in this table; for these ABIs, the information is in ..MMIIPPSS..ooppttiioonnss, which can be seen by entering the eellffdduummpp --rreegg or eellffdduummpp --oopp commands. DDYYNNAAMMIICC Points to information in the file needed by rrlldd(5). Includes the lliibblliisstt (which can be seen by entering the eellffdduummpp --DDll command), a symbol table (which can be seen by entering the eellffdduummpp --DDtt command), and other information. LLOOAADD Points to segments that are to be mapped into the memory image. The columns give various information about each segment, as follows: CCoolluummnn CCoonntteenntt OOffffsseett The offset in the file to the beginning of the segment. VVaaddddrr The virtual address of the beginning of the segment in the memory image of the file, assuming that it was mapped as described in the LLOOAADD entries. PPaaddddrr The same as VVaaddddrr. FFiilleesszz The size of the segment in the file. MMeemmsszz The size of the segment in the memory image. When MMeemmsszz is greater than FFiilleesszz, the bytes after FFiilleesszz are zero-filled. AAlliiggnn The alignment required by this section. If a segment is to be mapped somewhere into memory other than at VVaaddddrr, the new address must be congruent to VVaaddddrr modulo the alignment. In the preceding example, the first segment must always be loaded at a page boundary, and the second must always be loaded at a 64K boundary. RRWWXX Specifies the protections, read, write, or execute, for the segment. Programs that are linked with the --nnoonn__sshhaarreedd option on the compiler command line do not have a PPHHDDRR, IINNTTEERRPP, or DDYYNNAAMMIICC section. Thus, the eellffdduummpp --oo command is a convenient way to determine whether a program is linked as nonshared. For more information on this command, see the eellffdduummpp(1) man page. 88.. HHooww ddoo II bbuuiilldd aa DDSSOO?? Perform the following steps: 1. Build a _f_i_l_e..oo or _f_i_l_e..aa that contains all the routines you want to have in your _f_i_l_e..ssoo (your DSO). This can be done with a compiler and aarr(1). 2. Invoke lldd(1) with the --sshhaarreedd option. Normally, the extension ..ssoo is used to designate DSOs. Example 1: cc -c myobj.c ld -shared myobj.o -o myobj.so Example 2: cc -c myobj.c cc -shared myobj.o -o myobj.so Example 3: <build libmine.a the usual way> ld -shared -all libmine.a -o libmine.so The --aallll option in the third example directs lldd(1) to include all the routines in the library. This option is needed because there are not undefined references in the program, which is the usual way for lldd(1) to determine whether to load files from an archive. 99.. WWhheerree ddooeess tthhee ssyysstteemm llooookk ffoorr DDSSOOss aatt rruunnttiimmee?? The search path for DSOs is acquired in the following order for programs compiled with the --3322 compiler option: 1. The path of the DSO if given in the lliibblliisstt 2. In any directories specified with the --rrppaatthh option when the executable file was built 3. In any directory specified by the LLDD__LLIIBBRRAARRYY__PPAATTHH environment variable, if it is defined 4. In the directories in the default path, which is //uussrr//lliibb, //uussrr//lliibb//iinntteerrnnaall, //lliibb, //lliibb//ccmmppllrrss//cccc, //uussrr//lliibb//ccmmppllrrss//cccc, //oopptt//lliibb. If the __RRLLDD__RROOOOTT environment variable is defined, then its value is appended to the front of any path specified by the --rrppaatthh option and the default path. __RRLLDD__RROOOOTT itself is a colon (::) separated list. For programs compiled with the --nn3322 compiler option, the rules are similar, but the following differences exist: * The LLDD__LLIIBBRRAARRYYNN3322__PPAATTHH is used if LLDD__LLIIBBRRAARRYY__PPAATTHH is defined. * __RRLLDDNN3322__RROOOOTT is used for the list of paths * The default path directory list is //uussrr//lliibb3322, //uussrr//lliibb3322//iinntteerrnnaall, //lliibb3322, //oopptt//lliibb3322. For programs compiled with the --6644 compiler option, the rules are similar, but the following differences exist: * The LLDD__LLIIBBRRAARRYY6644__PPAATTHH is used if LLDD__LLIIBBRRAARRYY__PPAATTHH is defined. * __RRLLDD6644__RROOOOTT is used for the list of paths. * The default path directory list is //uussrr//lliibb6644, //uussrr//lliibb6644//iinntteerrnnaall, //lliibb6644, //oopptt//lliibb6644. See the rrlldd(5) man page for more details. 1100.. WWhhaatt iiss QQuuiicckkssttaarrtt?? Quickstart is an optimization. Using an ssoo__llooccaattiioonnss file, lldd(1) prerelocates each DSO as if it had been loaded (or _l_i_n_k_e_d, which is the term often used) by lldd(1)) at the address in the ssoo__llooccaattiioonnss file. If no errors occur at startup, all DSOs map to their Quickstart addresses, and rrlldd(5) does not need to perform a relocation pass. When new software is installed with iinnsstt(1M) or sswwmmggrr(1M), rrqqssaallll(1) changes many DSO virtual addresses, attempting to ensure that all registered applications (written to //vvaarr//iinnsstt//..rrqqssffiilleess) can be Quickstarted. At the same time, rrqqssaallll(1) updates ssoo__llooccaattiioonnss. If more than one DSO attempts to map to the same address, the IRIX kernel moves one of them to an unused address range, and rrlldd(5) performs a relocation pass to fix the address references. If one or more of the DSOs linked against at static link time has changed by the time the program executes, rrlldd(5) performs extra work to ensure that symbols have been resolved to their proper value. 1111.. WWhhaatt iiss tthhee tthhee //uussrr//lliibb//ssoo__llooccaattiioonnss ffiillee?? After you build a DSO, a file called ssoo__llooccaattiioonnss is placed in the directory with the DSO. This file is a registry of DSOs. It maintains the default, or Quickstart, addresses of a group of DSOs that are guaranteed to never have their default locations overlap with one another. It is generated and updated by lldd(1) each time it builds a DSO. If you make substantial library changes between one build of the library and another, you should remove the ssoo__llooccaattiioonnss file before rebuilding the library. You do this because the information derived from the older build and put in the ssoo__llooccaattiioonnss files can make the new library build unsuccessful. rrqqssaallll(1) and rrqqss(1) can rearrange aa..oouutt files and DSOs to restore Quickstartability, so the ssoo__llooccaattiioonnss file is less important than it was before rrqqss(1) existed. For information on address ranges, see the following files: //uussrr//lliibb//ssoo__llooccaattiioonnss, //uussrr//lliibb3322//ssoo__llooccaattiioonnss, and //uussrr//lliibb6644//ssoo__llooccaattiioonnss. //uussrr//lliibb//ssoo__llooccaattiioonnss applies to programs compiled with the --3322 compiler option. //uussrr//lliibb3322//ssoo__llooccaattiioonnss applies to programs compiled with the --nn3322 compiler option. //uussrr//lliibb6644//ssoo__llooccaattiioonnss applies to programs compiled with the --6644 compiler option. These files represent the default layout for the system DSOs in the respective ABIs. Those who build DSOs may find it interesting to consult these files in order to avoid collisions between their DSOs and system DSOs. You do not need to consult this file if you merely run programs that use DSOs. If you build DSOs, two lldd(1) command options may be useful to you: --cchheecckk__rreeggiissttrryy and --uuppddaattee__rreeggiissttrryy. The --uuppddaattee__rreeggiissttrryy _l_o_c_a_t_i_o_n__f_i_l_e option examines _l_o_c_a_t_i_o_n__f_i_l_e and builds the current ..ssoo at a location that does not conflict with anything in the file (unless the current one is listed). The --uuppddaattee__rreeggiissttrryy option examines _l_o_c_a_t_i_o_n_s__f_i_l_e, as does --cchheecckk__rreeggiissttrryy, and attempts to write an entry for the ..ssoo file being built into _l_o_c_a_t_i_o_n_s__f_i_l_e. The --cchheecckk__rreeggiissttrryy _l_o_c_a_t_i_o_n__f_i_l_e option does not write to _l_o_c_a_t_i_o_n_s__f_i_l_e. If _l_o_c_a_t_i_o_n_s__f_i_l_e is not writable, the --uuppddaattee__rreeggiissttrryy option performs like the --cchheecckk__rreeggiissttrryy option. If _l_o_c_a_t_i_o_n_s__f_i_l_e is not readable or writable, the --cchheecckk__rreeggiissttrryy and --uuppddaattee__rreeggiissttrryy options may cause lldd(1) to generate one or more error messages. 1122.. WWhhaatt ddiirreeccttiivveess ccaann bbee ppuutt iinnttoo aa ssoo__llooccaattiioonnss ffiillee?? The following directives control the placement of new DSOs: * $$tteexxtt__aalliiggnn__ssiizzee==_a_l_i_g_n ppaaddddiinngg==_p_a_d__s_i_z_e and $$ddaattaa__aalliiggnn__ssiizzee==_a_l_i_g_n ppaaddddiinngg==_p_a_d__s_i_z_e These two directives specify the alignment and padding requirements for text and data segments, respectively. The size value in ssoo__llooccaattiioonn is calculated based on: section size + padding, aligned to the section align size. The align values for text and data, as well as the padding values, must be aligned to a bucket size. If not, lldd(1) generates a warning message and aligns these values to the bucket size. * $$ssttaarrtt__aaddddrreessss==_a_d_d_r Specifies the beginning address for DSOs. * $$ddaattaa__aafftteerr__tteexxtt==[ 11 | 00 ] Instructs the linker to place data immediately after the text at specified text and data alignment requirements. The default is 0. * _s_o__n_a_m_e [ ::_s_t == {{ ..tteexxtt || ..ddaattaa || $$_r_a_n_g_e] }} _b_a_s_e__a_d_d_r,,_p_a_d__s_i_z_e :: ]] ** This directive consists of the following elements: EElleemmeenntt CCoommppoossiittiioonn _s_o__n_a_m_e Full path name (or trailing component) of a DSO. _s_t String that identifies the start of the segment description. ..tteexxtt or ..ddaattaa or $$_r_a_n_g_e Specify either a segment type, text or data, or a _r_a_n_g_e. Specifying a _r_a_n_g_e limits the range of addresses that can be used. Specifications of ..tteexxtt or ..ddaattaa are for internal use only. _b_a_s_e__a_d_d_r Address at which the segment starts. _p_a_d__s_i_z_e Padded size of the segment WWAARRNNIINNGG:: The format and use of the ssoo__llooccaattiioonnss file is under review and may in the future move to a simpler format. Currently, only $$rraannggee should be specified, not ..tteexxtt or ..ddaattaa, in the specification. When building a DSO with the --cchheecckk__rreeggiissttrryy or --uuppddaattee__rreeggiissttrryy option of the lldd(1) command when there is already an entry that corresponds to this DSO in the ssoo__llooccaattiioonn file, the linker attempts to assign the same addresses for text and data. However, if the size of the DSO changes and does not fit in the specified location, the linker searches for another location. If the optional $$rraannggee comment is specified, the linker places the DSO in the specified range of addresses. If there is not enough room, a message is generated. A comment line can be inserted at any point a directive can be inserted. A comment is a line beginning with the number sign (##) character. 1133.. IIff II ddoonn''tt hhaavvee aa vvaalliidd ssoo__llooccaattiioonnss ffiillee,, ccaann II ggeenneerraattee oonnee ffrroomm aallll tthhee ..ssoo ffiilleess iinn //uussrr//lliibb?? Not easily. It is an error if the ssoo__llooccaattiioonnss is missing. Every ssoo__llooccaattiioonnss file is different because rrqqssaallll(1) reQuickstarts everything. If //vvaarr//iinnsstt//..rrqqssffiilleess is present, you could get a set of ssoo__llooccaattiioonnss files from a similar system and rerun rrqqssaallll(1) as iinnsstt(1M) and sswwmmggrr(1M) do. If you do this, make a back-up copy of ..rrqqssffiilleess before starting rrqqssaallll(1). NNOOTTEE:: If anything destroys or results in the loss of ..rrqqssffiilleess, the only way to recreate ..rrqqssffiilleess is to reinstall everything on the system. Make a back-up copy of ..rrqqssffiilleess. 1144.. HHooww eexxppeennssiivvee iiss iitt,, aatt rruunnttiimmee,, NNOOTT ttoo uussee tthhee --uuppddaattee__rreeggiissttrryy ooppttiioonn?? If you use rrqqssaallll(1) or rrqqss(1) to reQuickstart an application and its DSOs, then there need not be any cost. rrqqss(1) can make the DSOs Quickstartable regardless how the DSO addresses were determined. If you do not use rrqqss(1), then the lack of an updated registry can impose startup costs. It is very difficult to say how much a particular executable will suffer because it depends on which DSOs the program uses and whether they have been Quickstarted for the same address. When there is a conflict between two objects, one will be moved, which means that all addresses referring to names in that object need to be relocated. 1155.. HHooww aanndd wwhheenn wwiillll QQuuiicckkssttaarrtt bbee uusseedd?? The linker uses Quickstart unless there are unresolved symbols at static link time. Every executable and every DSO contains a list of objects that were examined at static link time when the object was made. This list also contains timestamps and checksums for each of the objects. Various levels of extra work are required if the timestamp or checksum changed in the library at runtime. 1166.. WWhhaatt aabboouutt rruunnttiimmee llooaaddiinngg uunnddeerr uusseerr ccoonnttrrooll?? The library allows you to dynamically load your own DSOs as needed. The individual library calls are as follows: * ddllooppeenn(3C), which opens a DSO. * ddllssyymm(3C), which finds the value of a name defined in an object. * ddllcclloossee(3C), which closes a DSO. * ddlleerrrroorr(3C), which reports errors. * ssggiiddllaadddd(3C), which functions much like ddllooppeenn(3C), but it exposes all symbols to the rest of the program. * ssggiiddllooppeenn__vveerrssiioonn(3C), which functions much like ddllooppeenn(3C), but it allows specifying a specific required version of the DSO. Consult the individual man pages for details. 1177.. WWhhaatt bbeenneeffiittss wwiillll II ggeett ffrroomm DDSSOOss?? Executables linked with DSOs are smaller because the DSOs are not part of the executable file image. Executables that use a DSO need not be relinked if a DSO is changed. After the updated DSO is installed, the executable picks it up automatically. DSOs allow application designers to make more machine-independent software. System-dependent routines can be given a uniform interface, and a DSO that implements that interface can be built for each different platform. Actual applications can be shipped to various platforms and run on them all. DSOs give applications the ability to change the binding of symbols at runtime and under user control. 1188.. WWhhaatt ccoossttss aarree aassssoocciiaatteedd wwiitthh DDSSOOss?? A DSO incurs two costs, both against performance. The first is a start-up cost incurred while rrlldd(5) maps in the various objects, performs symbol resolution, etc. This cost is usually small compared to the time it takes to contact the X server, for example. The second is the cost incurred when using position-independent code. A DSO's text must be compiled with the --KKPPIICC option in effect in order for the object file to be put into a DSO without further modification. Because this option is in effect by default, it is not necessary to specifiy it. By default, PIC is slower by 5% to 15%. With full optimization, however, the speed reduction can be near zero. PIC code seems to be worst on very small-leaf routines that access global data. Routines written in assembly language for non-PIC use (for example, routines written before PIC was available for IRIX) need to be modified before the --KKPPIICC option can be used. For more information on modifying your code, see the _M_I_P_S_p_r_o _A_s_s_e_m_b_l_y _L_a_n_g_u_a_g_e _P_r_o_g_r_a_m_m_e_r'_s _G_u_i_d_e. 1199.. MMuusstt mmaaiinn pprrooggrraammss tthhaatt wwaanntt ttoo uussee DDSSOOss uussee --KKPPIICC ffoorr ccoommppiillaattiioonn?? Yes. DSOs use --KKPPIICC so that PIC code is generated. Main programs are not generally position-independent, but they must still use the DSO calling convention when calling a routine that is defined in a DSO. In particular, this means that a main program must have a Global Offset Table (GOT) and the code that is generated must use it. Modules that will become part of main programs and modules that become part of DSOs must be compiled with the --KKPPIICC option in effect, which is enabled by default. 2200.. WWhhaatt ooppttiioonnss ddoo II hhaavvee wwhheenn bbuuiillddiinngg aa DDSSOO?? If you specify the --BB ddyynnaammiicc option while linking a DSO, symbols in the DSO are resolved in a nondefault manner. In particular, the runtime linker first tries to resolve symbols referenced in the object to symbols defined in the object instead of looking for definitions in objects in the order specified on the link line. The effect is that all symbols defined and used in such objects are non-preemptable. Ordinarily, symbol definitions could be preempted by a definition in an earlier DSO. When --BB ssyymmbboolliicc is specified, however, this is not the case. For more information on the --BB ddyynnaammiicc and --BB ssyymmbboolliicc options, see the lldd(1) man page. 2211.. WWhhaatt ddiiffffiiccuullttiieess mmaayy bbee aassssoocciiaatteedd wwiitthh DDSSOOss?? Behind most unexpected behavior is the fact that linking semantics are fundamentally different, but only in a subtle way. Assume that a program links with three libraries, lliibbAA, lliibbBB, and lliibbCC, in that order. Further assume that both lliibbAA and lliibbCC define symbol xx but don't use it. Further, assume that lliibbBB contains a reference to xx. Archive linking (the old way) would resolve lliibbBB's reference to xx to the definition in lliibbCC, whereas DSO linking resolves lliibbBB's reference to xx to the definition in lliibbAA. This is true because with archive linking, when lliibbAA is examined, there is no outstanding reference to xx. The definition of xx is not extracted from the archive. Later, when lliibbCC is examined, there is a reference to xx, so it is loaded. With DSOs, all the constituent object files have been joined into one object, so all symbol definitions are always present. The resolution rule is simple: take the definition in the object listed first. Thus, the definition in lliibbAA is used. Another unexpected occurrence is a _r_u_n_t_i_m_e _d_a_n_g_l_i_n_g _r_e_f_e_r_e_n_c_e. These occur when you build and link an application with no errors or warnings but later receive a message from rrlldd(5) stating that your program has unresolvable symbols. The problem here is that if you build a DSO as part of your program, the linker typically does not generate messages about undefined symbols during a link of a DSO. This is because undefined symbols are expected during such a build and are perfectly acceptable. If the main program does not use a symbol, however, it is not flagged as undefined during static linking. You can use the --nnoo__uunnrreessoollvveedd option to the lldd(1) command to avoid such unexpected behavior. If a particular object in an archive file (lliibbll..aa, for example) has an external reference to a data symbol, and the data symbol is expected to be defined in the main program, the linker does not try to resolve that external reference unless the object file in question was actually referenced by the main program. If that archive is turned into a DSO, the external data reference must be resolved whenever ANY function in the DSO is used, even if no function in the object file in question is ever called and no use is made of the external data symbol in question. This can lead to a scenario in which a link that worked with the archives builds a program that is terminated by the runtime linker (rrlldd(5)). Do not assume that you can convert libraries that contain external data symbols into DSOs. One remedy is to split the archive into several DSOs and place them on the lliibblliisstt of a master DSO. By default, rrlldd(5) does not try to resolve data symbols until the first call is made to a particular object. You can, however, inhibit the linker's attempt to resolve an offending external data symbol until a call is made to the object in which it is referenced. For example, suppose that eexxtt__ddaattaa..oo is an object that contains an undefined external reference. It resides in archive lliibbxxyyzz..aa. Here is how to isolate that external data reference: 1. Make eexxtt__ddaattaa..oo into a DSO all its own: % ar x libxyz.a has_ext_data.o % ld -shared ext_data.o -o ext_data.so 2. Make lliibbxxyyzz..ssoo, excluding eexxtt__ddaattaa..oo from being included directly. Instead, put it in the lliibblliisstt of lliibbxxyyzz..ssoo: % ld -shared -all -exclude ext_data.o libxyz.a ext_data.so -o libxyz.so In addition to the previously mentioned caveats, applications should not call ddllooppeenn(3C), ssggiiddllaadddd(3C), ddllcclloossee(3C), ssggiiddllooppeenn__vveerrssiioonn(3C), or ddlleerrrroorr(3C) from within a signal handler. This means that calling from within a signal handler calling a function that results in a DSO being delay-loaded is also wrong. Ensure that functions called (directly or indirectly) from signal handlers are already loaded before a signal handler is set up. Very few functions are safe to call from within a signal handler (POSIX specifies a few), and the delay-load functions (ddllooppeenn(3C), and so on) are not among them. 2222.. WWhhaatt sshhoouulldd II ddoo aabboouutt GGlloobbaall OOffffsseett TTaabbllee ((GGOOTT)) oovveerrffllooww?? GOT overflow has occured if you receive messages from the linker saying GGPP--rreellaattiivvee sseeccttiioonnss oovveerrffllooww bbyy 00xx?????? bbyytteess, GGOOTT oovveerrffllooww, or GGOOTT uunnrreeaacchhaabbllee. To fix this situation, perform one of more of the following steps: * Recompile with the --TTEENNVV::llaarrggee__ggoott==OONN option on your compiler command line. Only the large input file that is causing overflow needs to be recompiled with this option. * Break the large input _f_i_l_e..oo into two or more smaller files. * Use the --mm option on the lldd(1) command to obtian a link map. This map indicates large objects that you can recompile with --GG00 or some other small --GG value. Data objects affected by the --GG_n_u_m option are numeric literals, addreses (including those generated by the compiler), all C/C++ static veriables, and, if the --ssttaattiicc option is in effect, all Fortran local variables. For more information on the --GG_n_u_m option, see your compiler command line. 2233.. HHooww aarree mmuullttiippllee vveerrssiioonnss ooff DDSSOOss ssuuppppoorrtteedd?? You can associate DSOs and executables with a version number. This is intended to support interface changes. A _v_e_r_s_i_o_n _s_t_r_i_n_g consists of 3 parts and a period (..), as follows. The first part is the string ssggii. The second part is a decimal number, which is the major number. The third part is the period (..). The fourth part is a decimal number, which is the minor number. Hence the format: ssggii_m_a_j_o_r.._m_i_n_o_r. For a DSO to be versioned as ssggii11..00, add the --sseett__vveerrssiioonn ssggii11..00 option to the compiler or loader command line to build the DSO (cccc -- sshhaarreedd, lldd --sshhaarreedd, and so on). Whenever you make a compatible change, update the minor version number (the one after the period) and add the latest version string to colon-separated list of version strings. For example: --sseett__vveerrssiioonn ssggii11..00::ssggii11..11::ssggii11..33. Whenever you make an incompatible change, update the major version number. For example, use --sseett__vveerrssiioonn ssggii22..00. Change the file name of the old DSO by adding a period followed by the previous major number to the file name of the DSO. Do not change the soname of the object. No change to the file contents are necessary or desirable. Simply rename the file. 2244.. HHooww ddooeess vveerrssiioonniinngg wwoorrkk?? Note that in this answer, items marked SGI ONLY do not apply to MSIG ABI binaries; they apply only to binaries generated on IRIX systems using a means other than the aabbiicccc(1) or aabbiilldd(1) commands. Versioning is available for NON-ABI executables only. The ABI does not require objects to have versioning, nor does it require systems to recognize versioning. It allows objects to contain version strings, but it does not require systems to do anything with this information. NON-ABI compliant executables have the RRHHFF__SSGGII__OONNLLYY bit turned on in the ..ddyynnaammiicc section. This flag is reported by the eellffdduummpp(1) command when eellffdduummpp --LL --lloonngg is entered. Only executables with this flag turned on receive the versioning treatment described in this answer. RRHHFF__SSGGII__OONNLLYY is turned on by default. When an executable is linked against a DSO, the last entry of the DSO's version string is recorded in the executable as part of the lliibblliisstt. This can be examined by using the --DDll option to the eellffdduummpp(1) command. When an executable is linked, you may specify the --rreeqquuiirree__mmiinnoorr or --iiggnnoorree__mmiinnoorr options for each DSO linked against. If --rreeqquuiirree__mmiinnoorr is specified, a bit will be set in the flags field of the lliibblliisstt entry for the DSO in question. The default is --iiggnnoorree__mmiinnoorr. When an executable (ABI or RRHHFF__SSGGII__OONNLLYY) is run, rrlldd(5) searches for the proper file name in its usual search routine. (SGI_ONLY) If a file with the correct name is found, the version string in the lliibblliisstt is compared to the list of version strings in the DSO. If the LLLL__RREEQQUUIIRREE__MMIINNOORR bit is set in the lliibblliisstt entry and there is an exact match between the version string in the depender and one of the strings in the version list of the dependee, then that library is used. If the LLLL__RREEQQUUIIRREE__MMIINNOORR bit is clear and if there is a match of major versions, then that library is used. (SGI_ONLY) If no proper match is found, a new soname is built by taking the soname found in the executable's lliibblliisstt and the major number found in the version string that corresponds to that lliibblliisstt entry. They are put together as _s_o_n_a_m_e.._m_a_j_o_r. This is searched for as described previously. Version strings are matched as described previously. (SGI ONLY) If, for example, BB..ssoo has a lliibblliisstt entry with a version list for AA..ssoo and an AA..ssoo is loaded that has no version, the DSO is considered a match. If BB..ssoo has a lliibblliisstt entry with no version list for AA..ssoo, then the first AA..ssoo found is considered a match, no matter what version AA..ssoo is. File AA..ssoo with no version can be created, for example, if lldd(1)'s --sseett__vveerrssiioonn option was not used or if an empty string was provided as an argument to the --sseett__vveerrssiioonn option. (SGI ONLY) A version string with a missing major number is an error. rrlldd(5) behavior is not defined for such cases. 2255.. WWhhyy aarree tthhee gglloobbaall oobbjjeeccttss iinn mmyy CC++++ DDSSOO nnoott bbeeiinngg iinniittiiaalliizzeedd?? Did you link your DSO using the CCCC(1) command instead of using lldd(1) directly? See the C++ information in the LINKING AND BUILDING SHARED OBJECTS section of this man page. 2266.. WWhhyy aarree ssoommee lliibbrraarriieess oonnllyy aavvaaiillaabbllee aass aa DDSSOO wwhheerreeaass ootthheerr lliibbrraarriieess aarree aavvaaiillaabbllee aass bbootthh aa DDSSOO aanndd aann aarrcchhiivvee?? The ABI specifies the DSOs that must be on every system. The converse of that is that no one can assume that any other ..ssoo is on an ABI- conforming system. Libraries explicitly called out in the MIPS ABI are considered part of the system interface. Such libraries are shipped only in DSO form. Libraries that are not specified in the MIPS ABI must also be supplied in archive form to generate MIPS ABI compliant binaries using these libraries. For example, the libraries lliibbXX1111..ssoo and lliibbcc..ssoo..11 are explicitly called out in the MIPS ABI. This makes the DSO version of XXlliibb and lliibbcc a system interface. Other examples are lliibbssoocckkeett..ssoo and lliibbddll..ssoo, which are also only supplied as DSOs. Archive versions of lliibbXXtt..aa, lliibbXXmm..aa, lliibbmm..aa, lliibbmmaalllloocc..aa, and others are supplied because shared library versions of these libraries are not specified in the MIPS ABI. Therefore, they are not guaranteed to exist on all ABI conforming systems. 2277.. WWhheerree ccaann II ffiinndd mmoorree ddooccuummeennttaattiioonn oonn DDSSOOss?? Besides the IRIX documentation mentioned in the SEE ALSO section of this man page, you may also want to consult the System V Application Binary Interface and the _S_y_s_t_e_m _V _A_p_p_l_i_c_a_t_i_o_n _B_i_n_a_r_y _I_n_t_e_r_f_a_c_e -- _M_I_P_S _P_r_o_c_e_s_s_o_r _S_u_p_p_l_e_m_e_n_t, both of which can be accessed at hhttttpp::////wwwwww..mmiippssaabbii..oorrgg. 2288.. WWhhaatt aarree ssyymmbbooll bbiinnddiinngg pprroobblleemmss?? _S_y_m_b_o_l _b_i_n_d_i_n_g, also known as _n_a_m_e _r_e_s_o_l_u_t_i_o_n, is the process of determining the data or function to use for an external name reference. If you are developing executable files or DSOs, you need to address this topic, but if you are simply running predeveloped applications, you can assume that symbol binding has been resolved for you. All symbols for which there is only one definition are simple. The one and only definition is used. For global references, the general approach is to examine the set of DSOs on the list that rrlldd(5) builds at run time and to use the first definition found. If there is a weak definition, then the first of those is taken if and only if there is no strong definition. If there is a strong definition, which might better be called a typical definition, the strong definition is used. In C and C++, ##pprraaggmmaa wweeaakk is used to create a weak reference or definition. Typically, DSOs are added to rrlldd(5)'s list in breadth-first order, generating the transitive closure of all DSOs on the executable lliibblliisstt (as shown by the eellffdduummpp --DDll command). If the application calls ssggiiddllaadddd(3C) or has any delay-loaded DSOs, those DSOs are added to the end of rrlldd(5)'s DSO list when they are actually loaded. If the loading is different with different data (that is, if the application calls functions that cause ssggiiddllaadddd(3C) or -delay-load operations in a different order at different times), the list of DSOs may be not have the same ordering. If there are multiple definitions, the first definition on rrlldd(5)'s list of DSOs for the executable is be used. If all definitions are weak definitions, the resolution proceeds conceptually identically to the strong case. If there is at least one strong and one weak definition of a symbol things, resolution proceeds as follows: 1. If a strong definition is in a DSO loaded into memory, it supersedes any weak definitions loaded. 2. If a weak definition is loaded and no strong definition is loaded, the weak definition is used. If an ssggiiddllaadddd(3C) or -delay-load operation causes a strong definition to be loaded, the symbol may or may not be rebound to the new strong definition. To avoid this unpredictable behavior, you may need to relink or rewrite your program with the following aspects of symbol resolution in mind: * You may obtain unexpected results if a strong symbol definition is loaded after a weak definition. In these cases, some calls may refer to one version and some to another, possibly within the same execution. * The order in which your executable calls functions or performs ssggiiddllaadddd(3C) or delay-load operations can affect symbol resolution. * Symbols that remain undefined after linking can affect symbol resolution. 3. Weak symbols were defined to allow ISO/ANSI C program to, for example, implement their own wwrriittee(()) operation while not affecting the operation of ffwwrriittee(()) and other ISO C calls and while still allowing another application to choose to call the lliibbcc wwrriittee(()) routine. It was expected that the strong symbol would be visible at the same time as the weak symbol. If both are visible at the same time they work predictably. But, as explained previously, if the weak symbol is visible when the strong symbol is not, the program can exhibit unexpected and unpredictable behavior. 2299.. AArree tthheerree nneeggaattiivvee aassppeeccttss ttoo uussiinngg ddllcclloossee(3C)? Because of symbol definition order rules, do not perform a ddllcclloossee(3C) on a DSO that was initially opened by a call to ssggiiddllaadddd(3C). For more information on this, see NAMESPACE ISSUES on the ddllooppeenn(3C) man page. SSEEEE AALLSSOO cccc(1), CCCC(1), eellffdduummpp(1), ff9900(1), ff7777(1), lldd(1). eexxeecc(2), nnsspprroocc(2), ssiiggpprrooccmmaasskk(2), sspprroocc(2), sspprrooccsspp(2). ddllcclloossee(3C), ddlleerrrroorr(3C), ddllooppeenn(3C), ddllssyymm(3C), mmaalllloocc(3C), mmaalllloocc(3F), pptthhrreeaadd__mmuutteexx__lloocckk(3P), sseettllooccaallee(3C), ssggiiddllaadddd(3C), ssggiiddllooppeenn__vveerrssiioonn(3C), ssggiiggeettddssoovveerrssiioonn(3C). ccaappaabbiilliittiieess(4), ccaappaabbiilliittyy(4). aabbii(5), ggpp__oovveerrffllooww(5), rrlldd(5). _M_I_P_S_p_r_o _C_o_m_p_i_l_i_n_g _a_n_d _P_e_r_f_o_r_m_a_n_c_e _T_u_n_i_n_g _G_u_i_d_e _M_I_P_S_p_r_o _6_4-_B_i_t _P_o_r_t_i_n_g _a_n_d _T_r_a_n_s_i_t_i_o_n _G_u_i_d_e _M_I_P_S_p_r_o _A_s_s_e_m_b_l_y _L_a_n_g_u_a_g_e _P_r_o_g_r_a_m_m_e_r'_s _G_u_i_d_e hhttttpp::////wwwwww..mmiippssaabbii..oorrgg This man page is available only online.